Skip to content

Conversation

PlaidCat
Copy link
Collaborator

Since we need to make sure external contributors code actually compiles prior to merging. To get access to the forked repos merge request we need to switch over our push to pull_request. In addition we're fixing up some Naming Conventions, adding aarch64 to this branch and fixing the naming so that we can quickly identify if the CI is for x86_64 or aarch64.

Also disable the process-pull-request until the utf-8 situation is resolved.

Exaple of it working on a PR
#75

Since we need to make sure external contributors code actually compiles
prior to merging. To get access to the forked repos merge request we
need to switch over our push to pull_request. In addition we're fixing up
some Naming Conventions, adding aarch64 to this branch and fixing the naming
so that we can quickly identify if the CI is for x86_64 or aarch64.

Also disable the process-pull-request until the `utf-8` situation is
resolved.
git config --global --add safe.directory /__w/kernel-src-tree/kernel-src-tree
cp configs/kernel-4.18.0-aarch64.config .config
make olddefconfig
make -j8
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume we are using runners that have greater than 8 cores? should we bump this if we have boxes with more cores?

Copy link
Collaborator Author

@PlaidCat PlaidCat Jan 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe they're 8 cores

Yeah that would make sense because we need large ones and 16cpu is likely overkill:
https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners#specifications-for-general-larger-runners

Copy link

@thefossguy-ciq thefossguy-ciq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also run a kABI check in the PR? Just in case someone (me) forgets to do it before pushing?

@PlaidCat
Copy link
Collaborator Author

PlaidCat commented Jan 23, 2025

Should we also run a kABI check in the PR? Just in case someone (me) forgets to do it before pushing?

We DO NOT push to branches without full PR (2pr specifically) and checks included in the PR, I've also long since disabled pushing to the base branches.

But yes its on the buckets list, this is just getting the builds working prior to merge rather than on push which is only run after merge for FORKED contributors

@PlaidCat PlaidCat merged commit 8babeea into ciqlts8_6 Jan 23, 2025
2 checks passed
@PlaidCat PlaidCat deleted the {jmaple}_ciqlts8_6 branch January 23, 2025 16:29
github-actions bot pushed a commit that referenced this pull request Oct 7, 2025
For 8-bit and 16-bit sign-extention mov instructions, it can use the
native instructions ext.w.b and ext.w.h directly, no need to use the
temporary t1 register, just remove the redundant operations.

Here are the test results:

  # modprobe test_bpf test_range=81,84
  # dmesg -t | tail -5
  test_bpf: #81 ALU_MOVSX | BPF_B jited:1 5 PASS
  test_bpf: #82 ALU_MOVSX | BPF_H jited:1 5 PASS
  test_bpf: #83 ALU64_MOVSX | BPF_B jited:1 5 PASS
  test_bpf: #84 ALU64_MOVSX | BPF_H jited:1 5 PASS
  test_bpf: Summary: 4 PASSED, 0 FAILED, [4/4 JIT'ed]

Acked-by: Hengqi Chen <[email protected]>
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants